The Internet and the World Wide Web (the “Web”) have become ubiquitous. Content providers (publishers) now use the Internet (and, particularly, the Web) to provide all sorts of content to numerous clients all over the world. In order to offload the job of serving some or all of their properties, many content providers now subscribe to content delivery networks (CDNs). Using a CDN, content can be served to clients from the CDN (i.e., from one or more servers in the CDN) instead of from the content provider's server(s). In a caching CDN, content may also be cached on some or all of the CDN servers, either before being served or in response to specific requests for that content. Having content cached within edge servers of the CDN enhances the performance of the CDN because the content does not have to be retrieved from origin servers or other locations, which are less efficient than edge servers in providing content.
Numerous forms of content, also referred to as resources, may be served from the CDN. For example, television shows and movies may now be accessed from any number of Web sites, and the shows and movies may actually be served from the CDN. Print newspapers have migrated to the Web and provide portals through which clients operating some form of computing device (e.g., PC, smart phone, or tablet), with a browser may access numerous forms of properties, such as short video clips, articles, images, and audio tracks. Software updates and patches, once only provided on disc and mailed to recipients, are now routinely distributed to devices using only network connections, and the updates and patches are often delivered from a CDN.
Traditionally, the CDN determines which property the request is for, and hence whether the request is for a legitimate subscriber (customer) of the CDN, by inspection of the incoming request. Generally speaking, each customer of a CDN will have at least one property configured on the CDN. The property specifies the hostname of the origin, the port number used by the origin, the protocol used by the origin, and other parameters. More specifically, determining legitimate requests thus involves inspection of the incoming Host: header and in certain specialized cases the first path element(s) (e.g., for the shared certificate secure sockets layer (SSL) service or the application name in the case of real-time messaging protocol (RTMP)). In such a situation, each Host: header (or top level path element, etc.) that may be presented to the CDN is pre-registered with the CDN as an alias for some property, and matching with the preconfigured property correlates with a legitimate request.
In some situations, a third party, such as a web site hosting company provides CDN reseller services to its customers. So, the third party does not actually operate a CDN but instead resells to its customers the CDN services of a separate CDN provider. In a high volume reseller model, this would mean that a very large and changing number of such aliases would be created and tracked by the CDN, and that the property creation and update rate of such would likely be equally high. Conventional CDNs are not particularly well equipped to deal with very large numbers of properties or with a high modification rate to the associated alias tables or property parameters.
It is with these observations in mind, among others, that various aspects of the present disclosure were conceived and developed.